The Arsenal Files 1

home *** CD-ROM | disk | FTP | other *** search

/ The Arsenal Files 1 / The Arsenal Files (Arsenal Computer).ISO / bbs / tm0302.txt < prev next >

Wrap

Text File | 1994-01-23 | 16.3 KB | 399 lines

SEA Technical Memorandum #0302, GROUP 2.16; Undocumented Features Last updated: October 14, 1989 Copyright 1988,89 by System Enhancement Associates, Inc. GROUP 2.16 Undocumented Features The purpose of this document is to document the undocumented features of the GROUP GroupMail conferencing program as of version 2.16, released in October of 1989. These features remain undocumented, even if documented by this document. The GroupMail conferencing system is, by design, a pickup system instead of a delivery system. If at all possible, it should be used as such, because that is how GroupMail avoids the bulk of the technical problems associated with echomail. However, at least one popular network mailer is not capable of properly negotiating a file update request, which is the mechanism by which GroupMail functions. Until that can be rectified, GROUP requires some sort of delivery mechanism in order to link such systems into GroupMail. If a file named "DELIVER.GRP" is placed in the SEAdog directory, then GROUP 2.16 will use it as a delivery list, and create file attach messages for each new GroupMail archive as it is posted by GROUP PACK (for a top star) or GROUP IN (by a middle star). The format of the DELIVER.GRP file will look very familiar to those acquainted with echomail. The DELIVER.GRP file is a normal ASCII text file. Each line begins with the name of a group conference, with the remainder of the line being a list of network addresses to which it should be delivered. A conference may be listed more than once, in which case it is addative. For example, a possible DELIVER.GRP file might be: BLATZ 520/1015 107/528 GNORF 107/528 GNORF 520/1015 By adding support of a delivery mechanism, we open the door to all the troubles echomail is heir to. However, the door is open only a tiny crack at this time. The single biggest problem with a delivery system is that of faulty topologies that cause duplicate messages. This is largely avoided from the start because all duplicate GroupMail archives have the same name. The remaining opportunities for duplicate messages to be generated are avoided because GROUP 2.16 refrains from unpacking any GroupMail archive that is older than the "target file" for that conference (unless the /S option is given). See also TM0304, "High Volume GroupMail". GROUP 2.16 implements the following undocumented option switches: /Q With LIST only. This causes the LIST command to display conference switches interpretively. GROUP makes certain "sanity checks" on its conference switches. For example, it is not possible to have a passthru area if you are the top star for that area. Executing a GROUP LIST with the /Q switch will give a report of what switches were active after all sanity checks and all defaults. GROUP 2.16 implements the following undocumented command line arguments: LINK This instructs GROUP to relink the message threads in all of its message areas. This will also invoke "dup killing" in ALL areas, not just ones where you are the top star (see below). READ This instructs GROUP to load the SEAdog MAIL program if any messages have been unpacked. GET <path> This instructs GROUP to seek new GroupMail archives in the named directory. CLEAN This instructs GROUP to delete packets on hold that are older than the specified retention period. This is normally done automatically when new packets are posted. This command forces it to happen on demand. This command is used primarily by Burt Juda in running the EchoGate system. ASK! This is an emphatic "ask" command, similar to the emphatic "PACK!" command. It causes GROUP to generate update requests only for those conferences that are designated with the "/!" switch. This feature is undocumented because we may decide to replace it with a more flexible multi-tiered system. The READ function is especially useful in a "point system", as it allows for commands of the form: group ask now in read out now This causes GROUP to generate file requests, dial out for updates, import anything it gets, fire up MAIL to read them (if it got anything), export anything you entered, and then fire up MAILER to ship what you typed (if anything). The GET function is especially intended for use on local area networks and similar environments. It performs a local equivalent of the ASK function. For example, to obtain and unpack GroupMail archives from another system whose holding area is accessible via a LAN as G:\MAIL\GRPHOLD, the appropriate command would be: group get g:\mail\grphold in To better facilitate the use of ARCmail for group traffic going to uplinks, GROUP 2.16 creates and maintains a file called "UPLINKS". After any given run of GROUP, this file will exist if any traffic to uplinks was found, and will contain a list of the uplinks concerned. The file will be deleted if no traffic to uplinks was found. This allows for easy triggering of ARCmail in a batch file as follows: group in out if exist UPLINKS arcmail to UPLINKS Since ARCmail does not worry about message origins, this has the advantage of automating the forwarding of middle-star traffic to uplinks. GROUP keeps track of almost everything in the AREAS.DOG file. However, there are a few general things it needs to know that can't be stored there. These are overall system parameters that you won't normally need to do anything about. But just in case, you can set them from the GROUP system parameter screen. You access the system parameter screen by giving the command: GROUP EDIT You should then see a screen that looks like this: Group Mail System Parameters -- Hit ESCape to exit Link reply threads: YES Move packets on a GET: NO Scan for duplicates: NO Strip VIA lines on a PACK: YES Keep outgoing messages: NO Kill messages during PACK: NO Kill bounceback messages: NO Log descriptions instead of stats: NO Kill outdated archives: NO Rule posting interval: 30 days Kill "Ping!" messages: NO Ping interval: 0 days Name of areas file: AREAS.DOG Name of statistics log: GROUP.LOG Name of pickup file: PICKUP.DOG Name of delivery list: DELIVER.GRP Name of uplink file: UPLINKS Name of origin files: ORIGIN Name of holding directory: GRPHOLD Group mail staging area #1: GROUP #2: #3: #4: #5: #6: #7: #8: #9: One of the parameters will be highlited. Use your cursor arrows to highlight the parameter you wish to change, and then type your change. The various YES/NO parameters are set by hitting either a "Y" (for YES) or an "N" (for NO). Hit the "Escape" key when you're done. We'll now go over most of those parameters: Link reply threads This tells GROUP if it should relink reply threads in your message bases after new messages are imported. GROUP does this by default, but you may want to turn this off if you have a slow disk or a lot of very large conferences. Scan for duplicates This is related to linking reply threads. GroupMail does not normally have a problem with duplicate messages, but during the interim period while GroupMail gets connected to echomail, it can "inherit" duplicates from echomail. If you set this to "YES", then GROUP will scan for duplicates in any conference where you are the top star. This will happen automatically any time messages are imported into your conference. You can also force this to happen in any and all of your conferences by giving a GROUP LINK command. In this case, GROUP will scan for duplicates even if you are not the top star. Move packets on a GET This tells GROUP if it should delete the packets it's copied during a GET command. Keep outgoing messages GROUP normally deletes an outgoing message once it's been mailed to your uplink. If this option is "YES", then GROUP will instead mark the message as "sent" and leave it. Kill bounceback messages As we said, GROUP normally deletes an outgoing message. When the message returns in the group archive you know everyone got it. If this option is "YES", then GROUP will discard any messages from your own system when it unpacks a group archive. If you set the previous option to "YES" and you leave this option at "NO", you'll end up with two copies of every message you enter. Kill messages during PACK If this option is "YES", then for any conference where you are the top star GROUP will delete the messages on your system once they have been packed in a GroupMail archive. Strip VIA lines on a PACK If this option is "YES", then for any conference where you are the top star GROUP will remove any "via lines" from messages as it packs them in a GroupMail archive. Via lines are hidden notes in the text of a message that show which systems it has passed through. They can be useful in diagnosing network topology problems, but removing them will reduce the size of your GroupMail archives. Log descriptions instead of stats When GROUP maintains its log file it calculates several columns of numbers showing message activity, but it only lists the conferences by name. If this option is "YES", then GROUP will report conference activity on a packet basis only, and in the space thus made available it will report the description of each conference, as it is listed in your areas file. This can be useful for a passthru midstar. Kill outdated archives When GROUP sees an outdated GroupMail archive (i.e. one that you've already unpacked), it normally prints a warning message and leaves the archive alone. When this option is "YES", GROUP will automatically delete outdated archives whenever it sees them. You should not normally ever see any outdated GroupMail archives. Rule posting interval This defines a rule posting interval, in days, for all conferences that you are the top star for. If you define a rule posting interval, then GROUP will look in each of your conferences for a text file named "RULES". If it finds one, then every so many days (defined by your rule posting interval) it will automatically generate a message in that conference with the contents of the RULES file as the text of the message. Ping interval This refers to the automatic topology mapping feature of GROUP 2.16. If you set a non-zero ping interval, then GROUP will "ping" every conference that you are the top star for every so many days (defined by the ping interval). This means that your system will create a "ping message" in each of your conferences, which will cause every member of your conferences to respond with topology data. The topology data is then compiled by your system to generate a topology map for your conference, which becomes the text of your next ping message. The topology report in your ping message will look something like this: 14d [20] 520/1015 1d [ 3] 107/566, Jim Flowers 1d [29] 41/35, Dale Lovell 1d [14] 440/1, Old Frog 1d [ 3] 520/528 1d 107/528, Burt Juda 1d [14] 520/557, Bill Vanglahn 4h 520/567, Bill Vanglahn [ 7] 520/583 26m [ 8] 49/2004, John Roberts Each line reports on one member of your conference. The first column is the "turnaround time". That is, how long it took for a given system to respond to your last ping, in days, hours, or minutes. Where this number is missing, it means that that system is a passthru midstar whose presence was inferred. The first entry is for your own system, which by definition has a zero turnaround time, so in this case the first column is your ping interval. The number in brackets is the retention period for that system, in days. Where that number is missing, the system is not a star system and hence has no retention period. The rest of the line gives the address and sysop name (where known) for the system. It is arranged and indented to show the conference linkages. For example, in this report we can see that 49/2004 (John Roberts) gets the conference from 520/583, who in turn gets it from the top star. Kill "Ping!" messages If you are a member of one or more conferences where the topstar has set a ping interval, but you aren't interested in seeing the ping messages, set this option to "YES". Name of areas file This tells GROUP the name of the areas file that lists all of your group conferences. Normally this is "AREAS.DOG", and it's unlikely that you'd ever need to change it. Name of statistics log This tells GROUP what to call its statistics log. Normally this is "GROUP.LOG", and is placed in your SEAdog directory. Name of pickup file This tells GROUP what to call your pickup list. This is a file maintained automatically by GROUP which gives the appropriate PICKUP statements for a SEAdog acting as a star system. This file (normally called "PICKUP.DOG") should be included in your SEAdog configuration file with an "INCLUDE" statement. Name of delivery list This tells GROUP the name of your delivery list, if any. A delivery list (normally called "DELIVER.GRP") is similar to another file called "AREAS.BBS", sort of. Name of uplink file This tells GROUP what to call your uplink traffic list. This is a file maintained automatically by GROUP which gives the network addresses of any of your uplinks to which you have traffic (the file is deleted if you have no traffic for any of your uplinks). This is normally called "UPLINKS", so for example your batch file might contain: group out if exist uplinks arcmail to uplinks Name of origin files GROUP normally looks for "vanity lines" in a file named "ORIGIN". But so does some other software. If you have other software that is looking for ORIGIN files, then you might want to change this so that GROUP does not "collide" with what your other software expects. Name of holding directory This is the name of the directory in which pending GroupMail archives are kept (unless specified otherwise by the "/D" option). Normally this is called "GRPHOLD". Archives for passworded conferences are normally kept in subdirectories of this directory. This only applies if you are a star in one or more conferences. Group mail staging areas A "staging area" is a GroupMail directory. It contains high water marks and message subdirectories for group conferences. A message area must be in a GroupMail staging area in order to be considered a GroupMail area. You can define up to nine GroupMail staging areas (to put them on different drives, for example). A "group add" always adds to the last staging area, and a global ORIGIN file may only be in the first staging area. You should NOT remove or change a staging area that has groups in it! If you really must, then you should delete all of the conferences in that area, then remove or change that area, then re-add the groups.